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Summary:  The  paper  contains  an  overview  on  the  de- 
sign principles  and  main  characteristics  of  a family  of 
new,  strictly  object-oriented  combat  simulation  models 
called  COSIMAC  (COmbat  Simulation  Mode!  with  Aiito- 
mated  Control),  developed  at  our  Institute  since  1995. 
They  are  designed  as  dosed  models  which  means,  that  a 
detailed  modeling  of  the  highly  complicated  C’l  proc- 
esses is  indispensihle.  Additionally,  the  option  of  an  in- 
teractive man/machine  interface  is  implemented,  which 
offers  the  possibility  of  manual  control  on  different  com- 
mand <&  control  levels  for  playing  against  computer  gen- 
erated (and  controlled)  forces,  for  experimenting  with 
"unconventional"  decisions,  and  for  developing  and  im- 
proving the  rule  system  in  a trial-and-error  fashion.  Fur- 
thermore, the  paper  describes  a general  architecture  for 
the  design  of  command  & control  modules,  which  off  ers 
the  possibility  of  describing  tactical/operational  inten- 
tions and  concepts  of  operation  in  a kind  of  battle  man- 
agement language  (multilayer  tactical  language 
concept),  the  terrain  representation,  attrition  and  move- 
ment modeling,  the  development  of  terrain  and  situation 
assessment  modules,  which  are  - together  w ith  a set  of 
so-called  planning  functions  and  spatial  and  procedural 
templates  - a prerequisite  for  the  rule  systems  that  gener- 
ate adequate  tactical  missions  and  orders  for  the  as- 
signed units  or  simulated  objects,  and,  finally,  the  main 
results,  conclusions  and  future  developments  of  the 
project. 


1 On  the  Development  of  the  New  Combat 
Simulation  Model  Family  COSIMAC 


1.1  Background  and  Main  Characteristics 
of  the  New  Models 

As  a contribution  to  the  NATO  RSG.  18  study  on  Stable 
Defense  (see  [Hofmann  et  al.  95])  and  in  context  with  two 
doctoral  thesises  at  our  Department  (see  [Tolk  95]  and 
[Schnurcr  96])  more  than  30,000  simulation  experiments 


on  division/brigade  level  have  been  performed  with  the 
closed,  rule  driven  battle  simulation  model  KOSMOS 
over  a period  of  four  years.  They  cover  more  than  340 
different  scenarios  featuring,  attacks  by  two  different 
types  of  generic  divisions  against  three  different  types  of 
defending  brigades  under  different  situational  conditions 
involving  three  types  of  terrain,  two  visibility  conditions, 
up  to  three  degrees  of  defense  preparation  and  different 
combat  modes  (e.g.,  with  or  without  a preceeding  delay- 
ing bailie).  Thus,  in  addilion  lo  addressing  Ihe  primary 
questions  raised,  e.g..  by  the  RSG.18,  the  experiments  of- 
fered a unique  opportunity  for  testing  a rather  complex 
model  in  the  light  of  results,  leading  to  a continuous  im- 
provement primarily  of  the  rule  sets  controlling  the  tacti- 
cal and  operational  decisions. 

One  of  the  experiences  we  gained  with  the  KOSMOS 
simulation  experiments  was,  that  - for  a further  substantial 
improvement  of  the  rule  sets  lhat  control  the  assigned 
combat  and  combat  support  units  - the  rule  system  must 
know  the  tactical/operational  intentions  and  the  concept 
of  operation  of  the  superior  command  and  control  level  in 
order  to  react  adequately.  This  particularilv  applies  to 
cases  of  surprising  events.  Otherwise  the  lower  units 
would  react  unadequately  or  - in  the  view  of  the  superior 
command  - in  a rather  self  sufficient  way. 

For  example,  the  battalion  commander  must  know  the 
concepi  of  operation  of  the  superior  brigade  to  react  ade- 
quately in  the  view  of  the  brigade.  In  reality,  the  battalion 
commander  knows  that  from  the  operational  order  or  the 
context  of  the  situation  (or  common  held  exercises  etc.). 

Therefore,  one  of  the  objectives  of  the  follow  ing  COSI- 
MAC project  was  to  describe  tactical/operational  inten- 
tions and  options,  and  the  corresponding  concepts  of 
operalion  for  a set  of  relevant  scenarios,  combat  modes 
and  command  levels  in  a computer  readable  way  (e.g.. 
with  a kind  of  tactical/operational  battle  management  lan- 
guage which  generates  spatial  and  procedural  templates) 
so  that  the  rule  system  could  operate  dynamically  in  ac- 
cordance w'ith  the  (long  term)  intentions  of  the  higher 
command  even  in  case  of  rapidly  changing  situational 
conditions  and/or  failure  of  the  communication  system. 
With  this  approach  it  should  also  be  possible  to  model  the 
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(so-called)  German  "Auftragstaktik",  a special  type  of 
mission-typc-tactics  which  offers,  among  others,  the 
lower  command  levels  a comparatively  high  degree  of  in- 
dependence and  flexibility  in  exploiting  favourable  op- 
portunities. 

Furthermore,  the  new  combat  simulation  system  should 
provide  a higher  resolution  than  KOSMOS,  to  enable 
modeling  on  the  basis  of  physically  measurable  input  data 
and  thus  being  no  longer  dependent  on  the  insertion  of  ag- 
gregated data  (i.c..  Lanchcstcr-cocfficicnts),  that  had  been 
derived  beforehand  by  running  a high  resolution  simula- 
tion model.  (Regarding  the  problems  incurred  in  deriving 
Lanchester-coefficients  on  the  basis  of  results  obtained  by 
running  a high  resolution  battle  simulation  model  see 
[Schaub  91]. 

Fig.  1.1  summarizes  the  main  characteristics  of  the  new 
combat  simulation  models  COS1MAC  in  comparison  with 
the  KOSMOS  model. 


• Higher  resolution  of  the  battlefield  (down  to  single 
weapon  systems,  no  Lanchester-approach  for 
attrition  modeling  for  the  major  weapon  systems) 

• Interactive  and/or  closed  model  version  at  the  user's 
disposal 

• Realistic  representation  of  military  C'l-proccsscs 
with  CJ-modules  down  to  lower  command  & 
control  levels  (single  item,  platoon,  company, 
battalion) 

• Development  of  sophisticated  terrain  analysis 
modules 

• Data  bank  oriented 

i • Running  on  PC’s  and  workstations  (hardware 
independent) 

• Strictly  object-oriented  with  SMALLTALK  or  C++ 


Figure  1.1:  Main  Characteristics  of  the  New  Combat 
Simulation  Models  COSIMAC  in  Comparison  with  the 
KOSMOS  Model 

1.2  Design  of  the  Central  Simulator 

Experiences  obtained  in  developing  combat  simulation 
systems  in  the  past  at  our  institute  have  shown  that  a flexi- 
ble architecture  requires  a strict  and  rigorous  separa- 
tion of  the  pure  combat  processes  of  the  basic  combat 
(or  combat  support)  elements  (objects  at  the  lowest  level 
of  resolution;  in  our  models,  e.g..  platoons  in 
COS1MAC-P  or  single  weapon  systems  in  COSIMAC- 
WS)  from  the  command  and  control  processes  which 
control  these  objects. 

A major  problem  was  constituted  in  "hidden”  assump- 
tions regarding  the  tactical  behavior  of  these  combat  ob- 
jects. Actually  such  assumptions  are  often  firmly  con- 
nected with  these  objects. 

In  order  to  create  a rigorous  separation  between  different 
processes  the  architecture  of  (he  new  models  follows  a 


concept  of  layers  (see  Fig.  1.2  ).  The  main  layers  are  es- 
tablished by  the  centra I simulator  and  a set  of  command 
& control  modules.  Besides  there  exist  explicit  interface 
layers  that  serve  as  an  additional  abstraction  and  explicit 
user  interface  layers. 

In  the  Central  Simulator  (see  Fig.  1.3)  the  terrain,  envi- 
ronmental data  (e.g.,  weather  data)  and  the  basic  combat 
(or  combat  support)  elements  as  well  as  their  associated 
models  are  being  administrated.  Furthermore  the  central 
simulator  controls  the  simulation.  The  combat  elements 
are  described  by  a set  of  mainly  physical  and/or  technical 
(input)  data.  The  elementary  processes  of  these  objects 
are  implemented  in  the  associated  models.  These  encom- 
pass reconnaissance,  attrition,  movement,  communication, 
manipulation  of  the  environment,  and  transport  of  combat 
elements.  Furthermore,  the  associated  models  imply  basic 
knowledge  for  command  & control  processes,  e.g.,  target 
acquisition  and  selection,  route  planning  etc. 

The  layer  of  the  command  & control  modules  consist 
of  the  CT -modules  for  the  different  C2 -authorities  and/or 
an  interactive  user  interface.  Furthermore,  the  C2-modules 
administrate  the  individual  perceived  situation  of  a 
C2-authority. 


Trie  avctvtoduro  <X  cur  now  MTul«<r* 


Figure  1.2:  General  Architecture  of  COSIMAC 

The  Central  Simulator  allows  the  access  to  the  basic  com- 
bat (or  combat  support)  elements  only  by  a set  of  elemen- 
tary orders  by  which  these  elements  are  being  controlled. 
This  set  of  elementary  orders  is  not  identical  with  the  bat- 
tle management  language  as  described  in  Chapter  3,  and 
which  will  be  used  only  between  and  within  the  com- 
mand & control  modules  and  moreover  will  also  be  much 
more  extensive.  For  this  very  reason  the  command  & con- 
trol modules  do  not  communicate  directly  with  their  asso- 
ciated combat  elements  but  rather  via  a further  interface 
object  Conversely,  the  communication  of  the  combat  ele- 
ments addressed  to  their  command  & control  modules 
also  works  via  an  interface.  Thereby  a strong  logical  sepa- 
ration between  the  combat  elements  and  command  & con- 
trol modules  can  be  achieved  thus  providing  an  easier 
exchangeability,  extension  and  optimizing  of  the  com- 
mand & control  functions.  (In  older  models  the  firm 
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connection  of  command  & control  knowledge  with  the 
basic  combat  elements  had  revealed  itself  as  an  impasse.  > 
Moreover,  this  design  principle  also  offers  the  possibility 
of  a "physical"  separation  between  the  command  & con- 
trol modules  and  the  combat  elements,  i.e.,  the  possibility 
of  running  the  simulation  on  several  computers  is  consid- 
erably facilitated. 


f igure  1.3:  Architecture  of  the  Central  Simulator  at  Pla- 
toon Level  (COS1MAC-P) 

Nevertheless,  elementary  command  & control  knowledge 
has  been  implemented  in  the  models  associated  with  the 
basic  combat  elements. 

The  reason  for  this  is  that  a strict  separation  of  all  elemen- 
tary command  & control  processes  from  the  basic  combat 
elements  would  cause  an  extremely  high  flow  of  informa- 
tion via  the  interface  between  the  Central  Simulator  and 
the  command  & control  modules.  Since,  however,  tacti- 
cally adequate  behavior  of  the  basic  combat  elements  is 
highly  dependent  on  the  specific  situation  and  location  il 
must  be  exchangeable  during  the  running  period.  There- 
fore. a single  combat  element  is  not  only  allotted  to  one 
associated  model  for  an  aspect  such  as,  c.g..  target  aquisi- 
tion  or  movement,  but  rather  to  several  models,  one  of 
which  is  the  currently  used  one. 

Since  the  tactical  behavior  of  the  basic  combat  elements 
used  in  the  Central  Simulator  is  defined  by  terrain  to  a 
high  degree,  the  representation  of  terrain  is  explained  in 
the  following  chapter. 

1.3  Terrain  Representation 

For  model  development,  implementation  and  lesling  we 
presently  employ  the  digital  maps  used  already  in  the  BA- 
SIS simulation  experiments'.  They  comprise  three  differ- 
ent pieces  of  real  terrain  in  Germany  and  resemble  the 
following  terrain  types: 


- mountainous/wooded  (Furth  im  Wald.  8*14  kmJ). 

- rolling  hills/partly  covered  (Bubach,  6*10  km2), 

- flat/open  (Grettstadt,  6*10  km2). 

They  contain  elevation,  terrain  vegetation  and  trafficabil- 
ity  data  for  square  grid  sizes  of  25,  50  or  100  m.  The  alti- 
tude resolution  is  10  cm,  resp.  1 m. 

The  altitude  of  the  different  combat  vehicles  as  well  as 
the  altitude  of  the  different  terrain  cells  are  considered 
when  checking  the  line  of  sight.  Additional  visibility  bar- 
riers are  taken  into  account.  These  obstacles  may  be  static 
(e.g..  buildings,  vegetation)  or  change  dynamically  during 
the  simulation  (e.g.,  to  represent  smoke  screens  dispensed 
by  artillery  or  combat  vehicles  to  protect  themselves). 

Moreover,  vector  data  referring  to  roads  and  rivers  were 
used  in  order  to  determine  a set  of  cell  transfer  velocities 
that  are  subject  to  the  four  orthogonal  directions  and  that 
rise  values  for  each  terrain  cell  calculated  in  connection 
with  vegetation  and  altitude  data.  This  enables  us  to  gen- 
erate and  store  these  values  in  advance,  according  to 
mounted  or  dismounted  basic  combat  elements  and,  if 
mounted,  to  the  different  types  of  vehicles  (i.e..  wheel, 
chain,  airborne,  etc.). 

In  addition  to  these  static  values  taken  mainly  from  the 
natural  conditions  of  the  regarded  terrain,  the  concept  of 
cell  transfer  velocities  can  also  be  extended  by  dynamic 
aspects  such  as  obstruction  and  fire.  This  allows  us  to 
build  simple  but  extremely  flexible  movement  models  for 
our  basic  combat  elements  in  combat  situations  that  are 
capable  of  considering  natural  terrain  obstacles  as  well  as 
obstructions  and  other  artificial  obstacles  and  moreover 
even  obstacles  caused  by  enemy  fire. 

Disregarding  the  cellular  terrain  representation  on  which 
most  of  the  internal  simulation  processes  are  based  with 
respect  to  the  basic  combat  elements  in  an  off-road  com- 
bat mode,  our  display  concept  also  permits  the  superim- 
posal  of  pure  bitmap-  or  vectordata-displays. 

In  addition  to  the  old  BASIS  terrain  data  we  have  digit- 
ized the  terrain  of  the  CMTC  HOHENFELS  in  a similar 
way  to  get  the  possibility  of  comparing  some  scenarios 
(initial  situation  and  combat  dynamics)  of  real  held  exer- 
cises in  the  CMTC  with  replayed  scenarios  performed 
with  the  COS1MAC  models. 

1.4  Attrition  and  Movement  of  the  Combat 
Elements 

Movement  Modeling 


' BASIS  is  a high  resolution,  stochastic  Monte  Carlo  -type  combat  simulation  model  developed  1982  - 84  in  PL1  for  a mainframe  com- 
puter at  our  University.  It  permits  the  detailed  simulation  of  battalion-size  ground  forces  defending  against  a sequence  of  regimental- 
size  attacker  forces  Resolution  goes  down  to  every  combat  vehicle  or  weapon  system.  It  is  a closed,  script  driven  model  (without 
C2-models)  and  was  extensively  used  for  a study  on  .Non-offensive  Defense  Options"  in  1984  - 85  and  the  derivation  of  Lanchester- 
coefficients  for  simulation  experiments  with  the  KOSMOS  model.  In  1992  it  was  re-implemented  in  PASCAL  on  an  Apollo  workstation 
and  in  1996  in  C++  on  a PC.  Presently  it  is  used  for  test  purposes,  e.g.,  for  comparing  the  results  of  the  pure  combat  processes  of  the 
new  model  COSIMAC  with  those  obtained  with  the  BASIS  model  For  further  information  on  the  BASIS  model  see  [Hofmann  et  al  84] 


The  modeling  of  movement  of  the  low  level  combat  ele- 
ments is  a decisive  process  in  every  high  resolution  com- 
bat simulation  system,  especially  if  the  system  is  able  to 

conduct  automated  route  planning. 

Since  COSIMAC  is  based  on  a square  grid  terrain  model 
we  first  implemented  the  algorithms  which  are  most  com- 
monly used  to  optimize  routes  in  grid  models,  the  Dy- 
namic Optimization  algorithm  or  a specific  version  of 
Diikstra's  algorithm  for  route  planning  (see,  e g..  [Fould 
1992]).  However,  in  order  to  improve  the  performance  of 
the  Central  Simulator  we  currently  use  a special 
algorithm,  which  turns  out  as  a mixture  of  Dynamic  Opti- 
mization. Dijkstra's  algorithm  and  Branching  & 
Bounding.  The  basic  idea  of  this  approach  is  to  reduce  the 
number  of  nodes  (or  terrain  cells)  permanently  labelled  by 
the  spirit  of  Branching  & Bounding  by  taking  into  ac- 
count not  only  the  time  (or  cost  of  movement)  from  the 
sLarling  to  the  regarded  terrain  cell  hut  also  some  estimate 
of  the  further  distance  from  the  regarded  node  to  the  tar- 
get terrain  cell,  furtheron,  the  possible  routes  of  a re- 
garded combat  element  (or  unit)  arc  confined  beforehand 
by  assigning  mobility  corridors.  In  other  words:  The  com- 
bat elements  can  only  move  within  predefined  corridors 
which  correspond  to  predefined  combat  sectors.  Addition- 
ally, we  made  some  research  on  simplified  heuristic  ver- 
sions of  this  algorithm  which  will  not  find  precisely  the 
real  optimum  in  any  case,  but  are  much  faster. 

In  many  combat  simulation  systems  usually  only  one  cri- 
teria is  chosen  for  the  route  planning: 

- time,  e.g.,  the  goal  of  optimization  is  to  minimize 
the  time  a combat  element  needs  to  reach  a (given) 
target  cell. 

We  consider  three  additional  criterias: 

- path  length,  e.g.,  minimizing  the  length  of  the  path 
between  the  current  position  and  the  target  cell, 
taking  regard  of  given  constraints, 

- concealment,  e.g.,  maximizing  the  protection 
against  sight  (visual  detection)  given  by  vegetation 
or  buildings,  and 

- altitude,  e.g.,  trying  to  find  a path  that  minimizes  the 
altitude  of  all  cells  you  tread  on  the  way  to  the 
target  cell.  (This  criteria  can  be  understood  as  an 
attempt  to  maximize  cover.) 

These  extensions  and  the  combination  of  them  not  only 
allow'  us  to  automate  route  planning,  they  do  also  provide 
us  with  the  ability  to  model  appropriate  tactical  behavior, 
for  instance  to  move  a combat  element  or  unit  "like  water 
flows"  or  to  choose  routes  which  avoid  weapon  engage- 
ment zones,  detected  or  supposed  mine  fields,  etc.  Fur- 
thermore, this  approach  makes  it  possible  to  design  a 
route  planning  algorithm  for  helicopters,  e.g..  using  a 
modified  version  of  the  "altitude-oriented”  algorithm. 

Attrition  Modeling 

In  accordance  with  the  different  classes  of  weapon 


systems  the  combat  simulation  system  COSIMAC  con- 
tains different  kinds  of  attrition  modeling  approaches. 
The  most  important  are  roughly  described  in  the  follow- 
ing chapters: 

• Attrition  model  for  the  direct  fire  weapon 

systems 

Regarding  the  direct  fire  weapons  the  attrition 
model  in  the  single  item  version  (COSIMAC-WS) 
operates  on  the  (individual)  single  shot  approach. 
For  the  platoon  level  (COS1MAC-P)  neither  a pure 
single-shot  model  on  the  single  w eapon  system  level 
w'ith  individual  fire  control  nor  an  aggregated 
Lanchester-equation  model  is  implemented.  Since  in 
the  regarded  version  platoons  are  the  basic  combat 
element,  it  is  assumed  that  all  major  weapon 
systems  of  a platoon  fire  at  the  same  moment  under 
the  control  of  the  platoon  leader  (or  leading  weapon 
system).  This  simplification  can  be  justified  by  the 
fact  that  the  lire  unit  of  the  combat  troops  is 
normally  the  platoon  that  contains  similarly 
equipped  vehicles.  Keeping  in  mind  this  abstraction, 
the  attrition  model  for  the  direct  fire  weapon 
systems  can  be  roughly  described  as  a multi-shot 
model  on  the  combat  element  level.  Moreover, 
COSIMAC  is  able  to  model  unguided  rockets, 
antitank  guided  missiles  and  firc-and-forget  missiles 
of  every  range,  taking  regard  of  possible 
countermeasures  during  flight  time. 

• Attrition  model  for  the  high-angle-fire 

The  model  for  the  high-angle-fire  (mortars,  artillery 
systems  and  rocket  launchers)  operates  on  a single 
shot  approach.  For  all  kinds  of  targets  (combat  or 
combat  support  units)  a special  spatial  distribution 
(spatial  template)  for  the  individual  weapon  systems 
is  assumed,  depending  on  their  activity  (see  Chapter 
2.2).  With  (his  approach  we  can  base  the  calculation 
of  losses  caused  by  high-angle-fire  on  the 
commonly  approved  concept  of  lethal  areas  around 
the  impact  points  of  the  fired  shells. 


2 C’l-Modeling 

Since  1997  we  have  been  working  with  emphasis  on  the 
development  of  first,  simple  command  & control  modules 
and  rule  sets  for  the  single  weapon  system,  platoon,  com- 
pany and  battalion  level.  A prototype  version  for  the  com- 
bat modes  attack  and  defense  is  ready  for  use.  The  next 
chapters  describe  the  main  design  principles  and  first  so- 
lulions. 

2.1  On  the  Development  of  Terrain  and 
Situation  Assessment  and  Planning 
Modules 

2.1.1  Terrain  Assessment  and  Force  Deploy- 
ment Modules 

Terrain  assessment  and  subsequent  force  deployment  are 
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major  and  indispensable  tasks  of  every  military  com- 
mander. Therefore  any  C1 -module  must  be  able  to  per- 
form at  least  some  of  their  subtasks.  This  is  especially 
true  and  a demanding  task  for  a detailed  terrain  model. 

We  started  with  the  development  of  a simple,  interactive 
terrain  assessment  and  force  deployment  tool  for  defense 
operations  on  single  item,  platoon,  company  and  battalion 
level  for  pieces  of  terrain  as  described  before. 

Input  data  were: 

• forward  edge  of  the  battlefield  (FEBA). 

• boundaries  of  the  defense  area  (defense  sector), 

• number  and  type  of  own  troops/friendly  forces, 

• point  of  main  defense  effort, 

• areas  of  field  fortifications  and  target  areas  for 
supporting  prearranged  artillery  fire. 

These  data  are  given  by  the  op-order  for  defense. 

In  a first  step,  the  algorithm  figures  out  all  points  or  areas 
of  interest  for  a defender  such  as,  e.g.: 

- large,  interrelated  areas  of  open  terrain,  of  forests 
and  of  urban  (built  up)  areas  (tow'ns  or  villages), 

- the  rims  of  stich  areas  with  respect  to  the  main 
defense  direction,  which  offer  defilade,  protection 
against  artillery  fire  and  free  firing  zones  for  the  low 
angle  fire  of  the  ow-n  combat  elements  (especially 
important  for  dismounted  infantry), 

- hills  and  other  points  or  areas  with  good  visibility 
conditions  such  as  observation  points  or  places  for 
weapons  w ith  long  range  direct  fire.  c.g..  long  range 
anti  tank  positions. 

In  the  next  step  the  program  deploys  the  own  basic  com- 
bat elements  (platoons  or  weapon  systems),  which  are 
available  for  the  defender  in  the  regarded  defense  area, 
into  their  initial  defense  positions  on  or  near  the  FEBA 
(or  into  the  security  line  or  into  positions  in  the  depth  ) by 
considering  (besides  the  points/areas  of  interest  of  the  re- 
garded terrain)  the  following  items: 

- type  and  maximum,  minimum,  and  effective  firing 
range  of  the  combat  elements  and  their  effective 
(terrain  dependent)  firing  zones  in  the  proposed 
positions, 

- the  degree  of  overlapping  between  the  different 
firing  zones  in  order  to  minimize  the  number  and 
size  of  dead  firing  zones, 

- the  point  of  main  defense  effort  (where  the  degree 
of  overlapping  fire  should  be  extremely  high),  and 

- the  (initial)  spatial  template  for  defense  operations, 
which  divides  the  defense  area  in  an  area  on  or  near 
the  security  line,  an  area  on  or  near  the  FEBA.  an 
area  of  positions  in  the  depth,  and  a rear  defense 
zone. 

Meanwhile,  this  module  was  extended  and  integrated  into 
the  simulator.  With  this  module  it  is  presently  possible  to 


assess  terrain  on  battalion  level  for  defense  purposes  and 
to  deploy  given  forces  to  their  initial  defense  positions. 
Furthermore,  we  extended  the  module  to  comprise  also 
terrain  assessment  and  force  deployment  for  attack  opera- 
tions. Input  data  for  this  module  are: 

• boundaries  of  the  attack  area. 

• line  of  departure. 

• objective  of  the  attack,  number  and  type  of  own 
troops/friendly  forces  and  reconnoited  enemy 
troops. 

• areas  of  friendly  and  (supposed  or  reconnoited) 
hostile  field  fortifications,  and  - as  an  option  - 

• one  or  more  intermediate  objective(s). 

2.1.2  Situation  Assessment  and  Planning 
Modules 

These  modules  comprise  a large  number  of  mathematical 
functions  that  may  be  used  in  situation  (and/or  threat)  as- 
sessment and  operations  planning 

Examples  for  situation  assessment  functions  are,  e.g., 

- force  ratios, 

- force  concentrations, 

- deep  penetrations  into  the  defense  sector, 

- open  flanks,  etc. 

(Many  of  them  are  derived  from  the  combat  geometTy.) 

Examples  for  ons-planning  functions  are,  e.g..  estimations 
w’ith  respect  to 

- speed,  space,  and  time  requirements, 

- availability  of  forces. 

- losses, 

- loss-exchange  ratios  for  planned  operations,  etc. 

A lot  of  these  functions  can  be  taken  from  the  KOSMOS 
model.  But  there  is  still  a considerable  amount  of  them 
w'hich  must  be  newly  developed,  especially  for  the  lower 
command  levels.  An  example  is  elaborated  in  Chapter 
2.4. 

2.2  On  the  Development  of  Spatial  and  Pro- 
cedural Templates  for  Generic  Weapon 
Systems.  Units  and  Force  Stuctures,  and 
a Genera]  Approach  for  the  Assessment 
of  Tactical  Options 

2.2.1  Definition  of  Generic  Weapon  Systems, 
Units,  and  Force  Stuctures 

With  regard  to  the  scope  of  this  project  to  reflect  on  gen- 
eral solutions  and  in  accordance  with  the  object-oriented 
design  principle  of  the  simulation  system  COSIMAC  we 
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are  primarily  interested  in  a general  scenario  design  prin- 
ciple which  covers  a large  variety  of  different  kinds  of 
weapon  systems,  unit  types,  and  force  structures.  There- 
fore. we  have  applied  for  this  project  the  modular  force 
design  principle  of  the  KOSMOS  simulation  experiments 
and  extended  it  to  the  lower  command  levels.  (For  more 
information  see  [Hofmann  et  al.  95]  or  [Hofmann,  Hof- 
mann 98].) 

2.2.2  Spatial  Templates 


Spatial  templates  are  defined  as  models  of  how  objects 
(e.g.,  weapon  systems,  platoons,  companies  etc.)  are  posi- 
lioned  and  oriented  relatively  to  other  objects.  On  all 
command  levels,  they  describe  (approximately)  the  spatial 
arrangement  (grouping,  formation)  of  units  and  sub-units 
depending  on  the  state  (e.g..  type  of  combat)  and  situa- 
tional conditions. 

Examples: 

- column  or  double  column  formation, 

- line  formation  (permits  excellent  fire  to  the  front), 

- wedge,  inverted  wedge  or  Vee-formation  (”Keil’\ 
’’Breitkeil”.  formations  used  when  the  enemy 
situation  is  vague  and  the  leader  requires  firepower 
to  the  front  and  the  flanks), 

- two-up  (a  formation  with  two  elements  disposed 
abreast,  the  remaining  elements  in  rear). 


Figure  2.3:  Inverted  Wedge  Formation  ("Breitkeil") 

Fig.  2.4  finally  shows  an  example  for  a chance  of  forma- 
tion from  the  wedge  over  the  double  column  to  the  in- 
verted wedge  formation  including  a change  in  direction  of 
the  whole  formation.  Intention  is  to  avoid  that  the  pla- 
toons interfere  with  others  by  overcrossing  and/or  outpac- 
ing the  movements  of  other  platoons. 

2.3  Procedural  Templates 

Procedural  Templates  are  defined  as  models  on  tactics, 
techniques  and/or  procedures  which  describe  how  objects 
or  units  on  all  command  levels  typically  operate  and  work 
together  in  different  combat  modes  (Order  of  Battle,  em- 
ployment of  forces,  activities,  time  schedules,  combat  dy- 
namics, etc). 


Fig.  2.2  show's  - as  an  example  - the  wedge  formation 
(’’Keif’).  It  was  designed  as  a ’’pulling"  template  which 
means,  that  the  leading  1.  platoon  - which  advances  to  an 
objective  area  on  the  best  route  as  described  in  Chapter 
1.4  - pulls  the  following  two  or  three  other  platoons.  They 
follow  dynamically  in  predefined  areas  looking  for  best 
positions  (with  respect  to  cover  or  field  of  fire)  for  their 
own,  whereas  the  overall  heading,  depth  and  width  of  the 
template  is  ordered  by  the  company  (or  leading  platoon). 


E.cstncted.Aieas 


Figure  2.2:  Wedge  Formation  ("Keil”) 

Fig.  2.3  depicts  the  inverted  wedge  or  Vee-formation 
("Breitkeil”)  which  turns  out  to  be  a "pushing”  template. 
In  this  case  the  1.  platoon  "pushes"  the  other  platoons  be- 
fore him  leading  and  controlling  them  as  described  before 
on  the  route  to  the  objective. 


IS 


Figure  2.4:  Change  of  Formation  and/or  Direction 
Examples: 


- leapfrogging  (e.g.,  one  combat  module  moves,  the 
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other  one  fires  (iiberschlagendes  Vorgehen))  or 

- advance  in  an  accordion-likc  manner 
(raupenformiges  Vorgehen),  but  also 

- schematic  representations  of  the  Order  of  Battle, 
employment  of  forces  etc.  for  the  different  kinds 
and  phases  of  an  operation  as  described  in  the  Field 
Manuals  (see,  e.g.,  FM  100-5  orHDv  231/100). 

Leapfrogging  and  advance  in  an  accordion-like  manner 
are  implemented  on  company  level. 

As  an  example  for  defense  operations  Fig.  2.5  depicts  the 
schematic  organization  of  a prepared  defense  by  a Mixed 
Mechanized  Infantry  Battalion  with  two  Mechanized  In- 
fantry Companies  side  by  side  in  front-line  positions  and 
the  Tank  Company  as  a reserve.  The  scenario  was  elabo- 
rated by  the  Tactical  Center  of  the  German  Army  (Tak- 
tikzentrum  des  Herres)  and  published  recently  in  [TRUP- 
PENPRAX1S  9/97], 

It  shows,  as  an  example,  the  "implementation”  (realisa- 
tion) of  a given  schematic  organization  of  a prepared  de- 
fence according  to  the  respective  German  Field  Manual 
(HDv  231/100)  into  an  assumed  "real”  situation  taking 
into  account  the  perceived  enemy  situation,  situation  of 
own  troops,  terrain  and  a variety  of  further  situational 
conditions. 


Figure  2.5:  Excerpt  from  the  Operation  Plan  of  a Pre- 
pared Defence  for  a Mixed  Mechanized  Infantry  Battalion 
[TRUPPENPRAX1S  9/97], 

2.4  A General  Approach  for  the  Allocation 
of  Fire  and  Forces  and  the  Assessment  of 
Tactical  Options 

Even  though  each  C2-authoritv  and  the  different  branches 
or  functional  staff  areas  have  their  own  C:-modules  (see 
Chapter  3),  a general  method  for  the  design  of  C:- 
modules  should  be  mentioned  at  this  moment:  the 


appliance  of  the  multi-dimensionai  utility  theory  for 

solving  a large  variety  of  decision  problems  from  the  tar- 
get allocation  problem  up  to  the  assessment  of  the  effec- 
tiveness of  tactical  options,  orders  and  missions,  a 
concept  that  has  already  proven  its  usefulness  in  the  KOS- 
MOS  model. 

Background  for  this  approach  was  the  experience  we 
made  when  asking  military  experts  for  rule  sets  for  prob- 
lems like,  e.g.,  target  allocation  to  artillery  batteries,  em- 
ployment of  reserves  etc.  It  was  very  hard  for  them  to  for- 
mulate general  decision  rules  in  a precise  "if  - then  - else" 
manner.  Most  often  the  answer  was  "that  depends  on  the 
situation",  specifying  a set  of  more  than  10  or  20  different 
influence  factors. 

The  multi-dimensional  utility  theory  approach  reduces  the 
general  problem  of  fire  or  force  allocation  on  all  com- 
mand levels  to  a m*n  allocation  problem  based  on  a m*n- 
utility-matrix  with  each  value  representing  the  expected 
utility,  calculated  by  using  specific,  multi-dimensional 
utility  functions.  Subsequently,  the  allocation  of  fire  or 
forces  could,  for  example,  be  made  in  the  sequence  of  the 
utility  values,  taking  also  into  account,  e.g.,  the  marginal 
utility. 

Multi-dimensional  utility  criteria  for  the  target  allocation 
problem  of  artillery'  batteries  regarding  one  allocation  pe- 
riod may  be,  e.g.. 

- expected,  weighed  damage  (expected  number  of 
destroyed  weapon  systems,  weighed  with  their 
values  in  the  specific  situation), 

- expected  effects  of  target  suppression  (often 
important  with  respect  to  infantry). 

- cost  (negative  utility)  of  the  target  engagement  (e.g.. 
cost  of  ammunition,  "cost”  of  being  detected,  etc.), 

- tactical/operational  aspects  or  urgency  for  allocating 
the  target'. 

For  more  information  see  [Schnurer  96]. 

The  corresponding  criteria  for  the  assessment  of  tactical 
options,  allocation  of  forces,  employment  of  reserves  may 
be.  e.g., 

- degree  (or  probability')  of  performing  the  given 
orders,  missions  (or  intents  of  the  higher  command 
& control  authority), 

- expected  weighed  losses  of  adversary  forces, 

- expected  weighed  losses  of  own  forces. 

With  this  approach  a large  variety  of  different  situational 
conditions  can  be  considered. 

However,  the  main  problem  of  this  approach  is  to  get 
proper  estimates  of  these  (situation  depending)  expected 
values.  This  holds  true  especially  for  the  evaluation  of 
(given)  tactical/operational  options  on  the  higher 


2 In  reality,  we  are  confronted  with  a very  complex  n-stage,  2-person-zero-sum  (game  theoretic)  allocation  problem  which  is  far  too 
complex  for  an  algorithmic  solution.  In  order  to  consider  at  least  some  aspects  of  the  dynamic  (or  n-stage)  dimension  of  the  problem 
this  aspect  was  introduced  as  an  additional  criterion.  Furthermore  it  offers  the  possibility  of  considering  the  tactical/operational  inten- 
tions of  the  higher  command  in  the  allocation  process 
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command  levels,  at  which  a kind  of  "simulation  in  ad- 
vance” to  get  these  values  would  be  indispensable. 

One  possibility  for  solving  the  problem  would  be  the  use 
of  the  same  detailed  stochastic  model  for  the  evaluation 
process  one  takes  for  the  simulated  ground  truth.  But  that 
would  be  very  (running)  time  consuming,  especially  if 
one  considers  that  a large  number  of  replications  would 
be  necessary  to  get  expected  (or  mean)  values.  A second 
possibility  is  the  development  of  own  aggregated,  ex- 
pected value  models  for  the  different  evaluation 
processes.  (But  this  would  cost  a lot  of  time  for 
development.) 

We  voted  for  the  second  option  and  designed  and 
implemented 

- a deterministic  (expected  value)  model  for  the  target 
allocation  problem  for  direct  and  high  angle  fire 
weapons.  (It  operates  mainly  on  the  same  input  data 
that  are  also  used  for  the  simulated  ground  truth  by 
the  detailed  Monte  Carlo  simulation  model.) 

- a comparatively  simple  aggregated  deterministic 
Lanchester  model,  which  offers  the  possibility  for  a 
dynamic  "simulation  in  advance"  for  a limited  time 
frame  to  get  estimated  results  for  the  (given)  tactical 
options  to  be  assessed.  The  model  operates  on  the 
perceived  situation  of  enemy  forces.  (For  calibration 
purposes  it  also  offers  the  possibility  of  working 
with  the  real  ground  truth.) 

Up  to  now,  one  important  common  principle  for  the  de- 
sign of  terrain  evaluation,  situation  assessment  and  plan- 
ning modules  within  the  C:-modeling  approach  has  been 
elaborated:  the  appliance  of  classical  algorithmic  a|»- 
proaches,  optimization  techniques  and  geometric 
analysis  as  far  as  possible  in  order  to  exploit  the  ad- 
vantages of  modern  computers  for  numerical 
solutions,  to  attain  robust  and  highly  efficient  solu- 
tions, and  to  reduce  the  number  of  "if  - than  - else" 
decision  rules.  But  this  is  not  sufficient.  In  the  next  chap- 
ter some  further  important  aspects  and  design  principles 
for  modem  command  decision  modeling  are  described. 


3 On  the  Development  of  a Tactical/Opera- 
tional Battle  Management  Language  and 
a General  Architecture  for  the  Design  of 
Command  & Control  Modules 


3.1  Overview 

The  Tactical/Opcrational  Battle  Management  Language 
should  offer  the  possibility  of  describing  (in  a formalized, 
computer  readable  manner)  tactical/operational  intentions 
and  concepts  of  operation  (as  described  in  an  Operation 
Plan)  and  deliver  the  prerequisites  for  breaking  down  a 
concept  of  operation  of  a higher  command  level  to 


individual  missions  and  battle  orders  for  the  subordinate 
combat  and  combat  support  units,  and  further  down  to  the 
simulated  objects  at  the  end  of  the  command  and  control 
chain.  And  this  should  be  done  - as  much  as  possible  - 
automatically. 

Taking  into  consideration  the  different  levels  of  aggrega- 
lion  between  a battalion  operation  plan  and  a platoon  or- 
der (which  are  the  elementary  orders  in  our  Central  Simu- 
lator at  platoon  level),  wc  are  convinced  that  the  main  ef- 
fort to  realize  an  operation  plan  is  connected  with  the  task 
of  breaking  down  this  plan  into  individual  missions  and 
orders  for  the  simulated  objects. 

3.2  On  a General  Architecture  for  the  De- 
sign of  C2-Modules 

3.2.1  Introductory  Considerations 

In  most  of  the  combat  simulation  systems  realized  hith- 
erto, the  modeling  of  the  command  & control  process  is 
confined  to  the  battalion  and  higher  command  levels.  This 
is  due  to  the  fact  that  on  these  levels  analytical  and  geo- 
metrical approaches  are  (regarded  as)  sufficient  to  model 
such  processes.  Bui  for  future  systems  it  is  impossible  to 
circumvent  the  modeling  of  at  least  some  aspects  of  com- 
mand & control  at  the  company,  platoon  and  weapon  sys- 
tem level. 

In  principle,  it  would  be  possible  to  design  a Combat 
Simulation  System  (CSS),  that  only  copes  with  command 
& control  processes  at  the  lower  echelons,  but  we  con- 
sider that  to  be  inappropriate,  since  some  of  the  most 
compelling  questions  concerning  the  automation  of  deci- 
sion making  at  the  lower  command  levels  are  closely 
linked  with  the  corresponding  events  at  the  higher  levels, 
for  instance: 

- breaking  down  the  operation  plan  of  a battalion  into 
concrete  orders  at  the  platoon  or  weapon  system 
level, 

- taking  into  account  the  higher  commander's  intent 
in  unexpected  situations  (with  disturbed 
communication)  and 

- taking  advantage  of  favorable  developments  of  the 
situation  without  neglecting  the  overall  plan  of  the 
superior  command  level. 

Therefore,  wc  advocate  for  a comprehensive  modeling  of 
both  iow'er  and  higher  command  levels  (at  least  battalion) 
C:-processes  w'lthin  one  CSS.  The  nexus  of  all  these  de- 
mands is  flexibility:  it  should  be  possible  to  replace  hu- 
man decision  makers  (man  in  the  loop)  with  C:-modules 
wherever  you  like  in  the  simulation.  This  attribute  is  es- 
sential especially  w'hen  CSS  are  applied  within  combat 
training  exercises. 

Facing  these  challenges  wc  have  developed  a new  archi- 
tecture for  combat  simulation  systems  for  the  last  four 
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years,  that  enables  us  to  design  command  & control  mod- 
ules for  each  command  level.  This  architecture  is  founded 
on  the  following  concepts: 

• separation  (as  far  as  possible)  of  the  elementary 
combat  processes  (movement,  reconnaissance, 
attrition,  etc.)  from  the  C:-processes  (central 
simulator  vs.  C2-processes  concept), 

• design  of  specific  tactical  languages  for  every 
command  level  and  for  different  branches  and  staff 
functions  to  describe  the  set  of  options  provided  by 
the  system  (multilayer  tactical  language  concept), 

• development  of  command  & control  modules  for 
every  command  level  and  branch  based  on  the 
corresponding  tactical  languages  (concept  of  the 
tailor-made  C2-modules), 

• division  of  the  types  of  combat  and  the  general 
battlefield  tasks  into  sped  lie  phases  to  reduce 
complexity  (phase  concept). 

• assignment  of  (a  limited  number  of)  options  to  each 
phase,  which  arc.  in  a first  approach,  given  to  the 
system  and  later  on  generated  automatically  (option 
concept), 

• evaluation  of  these  options  and  missions  with  a 

generalized  utility  theory  approach. 

• implementation  of  a special  function  to  recall 
superior  command  automatons  with  restricted 
information  in  order  to  model  "actions  in 
accordance  with  the  higher  commander's  intent” 
after  failure  of  the  communication  system 
(recall-function  concept,  for  more  details  see 
(Hofmann,  Hofmann  981), 

• implementation  of  an  exception-interruption 
concept  to  model  a second  aspect  of  mission  type 
tactics:  the  exploitation  of  favorable  situations,  and 

• strongly  object  oriented  programming.. 

3.2.2  The  Multilayer  Tactical  Language 
Concept  in  Detail 

In  closed  combat  simulation  systems  every'  tactical  lan- 
guage (developed  tor  a certain  echelon  and  a certain 
branch)  can  be  defined  as  the  set  of  instructions,  that  is 
used  to  conduct  the  course  of  the  battle  at  the  correspond- 
ing level.  These  instructions  could  be  simple  orders,  mis- 
sions or  even  (graphical)  operation  plans.  Thus  in  closed 
combat  simulation  systems  the  tactical  language  defines 
exactly  the  interface  between  a given  echelon  and  its  su- 
perior C2-automaton. 

In  interactive  combat  simulation  systems  the  tactical  lan- 
guage consists  of  the  menu  of  instructions,  which  is  at  the 
human  decision  maker’s  disposal. 

Ultimate  objective  of  the  programming  of  a general  simu- 
lation system  is  the  exact  correspondence  of  the  "human" 
and  the  "computer"  tactical  language,  since  this  is  the 
paramount  precondition  for  the  employment  of  a CSS  for 
command  post  exercises  on  different  echelons  without  ad- 
ditional (service)  personal.  Otherwise  the  exchange  of  hu- 
mans and  C'-automaton  within  the  system  in  justifiable 


time  would  be  impossible.  Figure  3.1  shows  the  corre- 
sponding interface  between  two  command  levels  accord- 
ing to  the  multilayer  tactical  language  concept.  (X,  Y and 
/ designate  a declining  order  of  echelons,  for  instance: 
brigade,  battalion  and  company.) 


Figure  3.1:  Transformation  of  Tactical  Decisions  into 
Concrete  Instructions 

This  concept  forces  both  human  decision  makers  and  C;- 
automatons  to  formulate  their  instructions  (sets  of  orders 
and  missions)  to  subordinate  units  with  expressions  being 
pail  of  the  corresponding  tactical  language. 

In  general,  human  commanders  will  first  make  a decision 
and  afterwards  translate  it  into  a sequence  of  instructions. 
Within  an  automaton  the  processing  of  the  data  can  also 
lead  directly  to  concrete  instructions  skipping  an  explicit 
decision. 

At  the  lowest  echelon  modeled  in  the  CSS,  the  decision 
will  be  transformed  into  a set  of  elementary  orders, 
thereby  controlling  the  elementary  combat  objects  (pla- 
toons, weapon  systems)  of  the  central  simulator. 

Following  this  procedure,  the  operation  plan  of  a unit,  for 
instance  a brigade,  will  be  transformed  into  more  detailed 
orders  step  by  step,  taking  account  of  the  capabilities  and 
competencies  of  the  respective  echelons  and  finally  deriv- 
ing instructions  to  command  the  elementary  combat 
objects. 

The  performance  of  such  a multilayer  tactical  language 
system  depends  mainly  on  the  scope  of  the  different  lan- 
guages. Hence  to  improve  the  system  their  extension  is  a 
supreme  task.  Since  human  decision  makers  (military 
leaders)  participate  in  (he  interactive  version  of  the  CSS  it 
is  also  advisable  to  carry  out  this  extension  in  a way 
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approaching  the  usual  military  custom. 

3.2.3  The  Concept  of  Tailor-made  C2- 
automatons 

In  general,  the  C3-automatons  for  the  closed  version  of  the 
CSS  cannot  be  designed  before  the  corresponding  tactical 
languages  are  developed.  This  is  due  to  the  fact  that  the 
automatons  are  tailored  for  the  languages:  Most  of  the 
modules  of  an  automaton  are  created  to  perform  the  tran- 
sition of  instructions  from  the  higher  level  tactical  lan- 
guage into  (more  detailed)  expressions  of  the  lower  level 
tactical  language.  Usually,  to  realize  this  transition  a cer- 
tain amount  of  supporting  modules  must  be  implemented. 
These  modules  include  part  of  the  tactical  knowledge  of  a 
human  decision  maker.  With  no  doubt,  this  is  the  most 
crucial  step  in  the  whole  development  of  the  simulation 
system,  which  can  only  be  done  by  means  of  gradually 
improved  prototypes. 

To  the  extent  the  tactical  languages  differ  from  each 
other,  the  automatons  will  differ  too.  In  fact,  a priori  there 
are  no  constraints  at  all  for  the  architecture  of  any 
automaton  (like,  for  example,  a general  scheme  of  the 
military  decision  making  process);  the  design  and  imple- 
mentation of  the  automatons  depend  only  on  the  require- 
ments of  the  languages. 

This  is  why  we  call  this  approach  the  concept  of  tailor- 
made  C3-automatons.  It  provides  us  with  the  ability  to  de- 
sign and  implement  a variety  of  different  C’-modulcs 
within  one  CSS.  Therefore,  such  a system  can  be  consid- 
ered as  a general  test  environment  for  the  development 
of  C2-automatons. 


and 

• an  explicit  decision  making  module,  which  connects 
all  the  information  provided  by  the  evaluation 
modules  with  the  different  options,  weighs  these 
options  up  and  eventually  chooses  one  of  them  for  a 
decision. 

Figure  3.2  show  s how  these  modules  can  constitute  a pro- 
totype of  a battalion  C;-automaton. 


Figure  3.2:  Possible  Architecture  for  a Battalion 

C3-automaton 

Of  course  this  is  only  one  exemplary  solution,  bul  it  cer- 
tainly comprises  the  main  elements  necessary  to  model 
military'  decision  making  at  the  battalion  echelon  in  gen- 
eral . 

3.2.5  The  Transformation  of  the  Battalions 
Commander’s  Intent  on  the  Company 
Level 

The  Company  Tactical  Language 


3.2.4  Modeling  Command  & Control  on  the 
Battalion  Level 

In  the  following  a view-  is  given  on  the  basic  modules  of  a 
decision  making  automaton  at  the  battalion  level.  Al- 
though it  can  only  be  a first  sketch,  W'e  think  that  this  list 
gives  a helpful  guideline.  What  we  need  is: 

• a mission  analysis  module  (considerably  simplified 
by  the  tactical  language  concept,  since  it  only 
searches  for  key  words  to  trigger  the  assessment 
modules), 

• an  intelligence  estimation  module  which  builds  up 
the  perceived  situation  and  must  finally  encompass 
a comprehensive  enemy  situation  and  threat 
assessment, 

• a module  to  analyze  and  project  the  own  tactical 
situation. 


The  company  tactical  language  (CTL)  mainly  serves  to 
translate  the  battalion  commander’s  decision  into  com- 
pany level  instructions.  Thus  the  question  is:  Which  as- 
pects of  combat  are  usually  performed  at  the  company 
level,  respectively:  What  are  the  corresponding  orders  to 
transform  the  commander’s  decision? 

Above  all  the  company  is  responsible  for  the  immediate 
coordination  of  fire  and  movement  - even  when  facing 
enemy  fire  and  difficult  terrain  - and  all  the  arrangements 
to  perform  it.  Consequently,  the  company  tactical  lan- 
guage must  allow  the  battalion  commander  to  set  the 
stage  for  this  coordination  w'hich  means  that  the  CTL  w'ill 
mostly  comprise  the  following  instmetions: 

• a concrete  movement  order,  if  needed  specified  with 

- an  objective. 

- if  need  to  be:  intermediate  objectives. 


a module  to  analyze  and  project  the  own  logistical 
situation, 

a terrain  assessment  module, 

a module  that  administers  pre-developed  options 
(courses  of  action)  or  generates  these  options  by 
itself  according  to  the  different  phases  of  combat. 


- a line  of  movement, 

- a velocity, 

- an  exact  time  to  start  the  movement 

- an  order  and  maybe 

- a formation. 
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• a fire  control  order  (addressing  chiefly  the 
clearance  of  fires)  and 

• a communication  order  (inevitable  for  the  reward 
passage  of  lines). 

A next  step  to  extend  the  scope  of  a general  CTL  surely 
includes: 

• an  emplacement  order,  subdivided  in 

- a detailed  fighting  position  order  and 

- an  order  to  occupy  a battle  area. 

• a set  of  logistical  orders  to  organize  supply  and 
maintenance, 

• an  order  to  attach/detach  platoons. 

• an  order  to  allot  sectors  of  observation  and  fire  and 

• a set  of  orders  to  command  the  combat  of 
dismounted  and  mounted  fighting  forces. 

With  this  set  of  orders  it  should  be  possible  to  "translate" 
most  of  the  battalion  commander’s  decision  into  concrete 
instructions  for  the  company. 

Realization  of  the  Company  Tactical  Language  In- 
structions within  the  Company  C2-automaton 

As  mentioned  before  decision  making  at  the  company 
level  differs  markedly  from  its  higher  level  counterparts. 
Instead  of  being  driven  hy  a general  information  process- 
ing leading  lo  a choice  among  differenl  options,  low  level 
command  resembles  frequently  a permanent  adaptation  to 
the  current  situation,  using  proven  actions  and 
arrangements. 

Therefore,  a straightforward  processing  of  the  battalion 
orders  is  seldom  feasible.  A very'  instructive  example  for 
this  difficulty'  is  the  tactical  movement  appropriate  to  ter- 
rain and  situation.  Without  a notion  of  the  combat  forma- 
tions (wedge,  column.  Vee-formation.  etc.)  and  the 
possibilities  to  advance  (by  bounds,  by  echelon,  leapfrog- 
ging or  accordion-like)  any  C'-automaton  will  fail  to  pro- 
duce reasonable  commands  for  the  platoon  level. 

In  order  to  solve  this  problem  we  endowed  the  company 
automaton  with  a set  of  supporting  modules,  reflecting 
exactly  this  kind  of  skill  and  knowledge.  Since  calling 
these  modules  is  quite  similar  to  calling  the  whole 
automaton  with  tactical  language  instructions,  we  have 
named  the  totality  of  these  modules  the  company  tactical 
realization  language  (CTRL).  It  is  essential  to  notice  that 
the  orders  triggering  these  support  modules  arc  not  part  of 
the  company  tactical  language  (CTL).  which  implies  that 
they  cannot  be  used  at  the  battalion  level  to  specify  the 
battalion  commander’s  decision.  In  fact,  they  are  not  ac- 
cessible for  him  at  all  (see  Figure  3.3).  Notwithstanding 
this  constraint  the  object-oriented  design  of  the  simulation 
system  permits  to  reuse  most  of  the  elements  of  the  tacti- 
cal realization  language  in  different  automatons. 


Figure  3.3:  Company  Tactical  Language  and  Company 
Tactical  Realization  Language 


4 Main  Results,  Conclusions  and  Future 
Developments 

One  of  the  main  efforts  is  the  development  of  robust  and 
highly  efficient  rule  sets  for  combat  simulation  systems 
(CSS)  with  automated  control.  For  higher  command  lev- 
els we  realized  this  task  with  the  CSS  KOSMOS.  During 
the  last  five  years  we  focused  our  attention  to  lower  eche- 
lons and  designed  and  implemented  the  COSIMAC  mod- 
els with  a completely  new  object  oriented  architecture  in 
order  to  evaluate  different  command  & control  automa- 
tons within  one  simulation  system. 

Among  others,  we  have 

» developed  a concept  for  the  description  of 
tactical/operational  intentions  and  concepts  of 
operation  with  a battle  management  language 
depending  on  the  different  command  & control 
levels  and  branches  or  functional  staff  areas, 

• developed  and  implemented  an  architecture  for  the 
design  of  C:-modules  to  break  down  these  concepts 
into  individual  mission  and  battle  orders  for  the 
subordinate  combat  and  combat  support  units. 
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• developed  and  implemented  some  detailed  modules 
for  route  planning,  terrain  assessment  for  defense 
and  attack  operations,  and  some  spartial  and 
procedural  templates  on  battalion,  company  and 
platoon  level, 

• implemented  a general  algorithm  based  on  a 
multi-dimensional  utility  theory  approach  for 
solving  the  general  allocation  problem  of  fire  and 
forces  in  order  to  come  on  robust  and  highly 
efficient  solutions,  and  to  reduce  the  complexity  and 
the  number  of  ”if  - then  - else”  decision  rules. 

Altogether,  we  come  to  the  conclusion  that  the  develop- 
ment of  C' -modules  at  different  command  levels  within 
one  combat  simulation  system  seems  to  be  a feasible  task; 
even  sophisticated  aspects  of  mission-type-tactics  like 

- acting  in  accordance  with  the  higher  commander’s 
intent  or 

- the  exploitation  of  favorable  unanticipated 
situations 

are  not  out  of  reach  of  modem  combat  simulation  systems 
with  automated  control. 

One  of  the  main  problems  of  this  approach  is  not  only  the 
complexity  of  the  problems  to  be  solved,  which  reveals 
the  limits  of  what  seems  possible  today.  In  our  view,  an- 
other major  problem  simply  consists  in  the  enormous 
amount  of  work,  which  leads  to  the  real  limits. 

But  the  project  is  going  on.  Our  MoD  was  pleased  with 
the  concept  and  decided  to  support  the  further  develop- 
ment of  COSIMAC  as  a research  and  study  project,  that 
concentrates  on  command  decision  modeling  for  different 
combat  modes  on  the  battalion,  company,  platoon  and 
single  weapon  syslem  level. 

In  the  long  run  we  think  about  a PC-based  training  or  a 
risk  evaluation  and  decision  support  tool,  by  means  of 
which  officers  may  test  a range  of  tactical  options  in  as- 
sumed scenarios  in  training  or  real  combat  situations  pro- 
viding them  a better  understanding  of  the  regarded 
tactical/operational  situation  and  assisting  their  decision 
making.  More  details  on  the  project  are  documented  in 
[Hofmann.  Hofmann  98]  and  [Hofmann  00], 
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